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Method of billing services, server and telecommunication sys- fU 

TEM 

[0001] The invention relates to billing of services in a telecommuni- 
cation systems which comprise servers of service providers and billing servers, 
5 which provide billing services. 

[0002] Electronic commerce (e-commerce) is a fast growing field of 
trade, which generally refers to all business by means of computers to sell 
products and services, particularly on the Internet. At its simplest opening of a 
commerce site on the Internet means opening of a WWW (World Wide Web) 

10 site on a server connected to the Internet. The minimum features the sales 
software of a service provider must have on the server include means for cre- 
ating a product catalogue, for management of a shopping basket and for re- 
ceiving orders. Other important features may include customer management, 
personification, auxiliary purchasing tools and handling of payment transac- 

15 tions. Furthermore, means or external interfaces are usually needed to imple- 
ment billing, warehouse management, logistics and reporting. Nowadays soft- 
ware packets are available which contain all the programs needed to create 
WWW services, including the Web server, browser, content management and 
program development tools. Examples of such software packets are Microsoft 

20 Site Server Commerce and IBM NetCommerce. By means of these one can 
create an appropriate client interface for displaying and browsing product cata- 
logues and for performing ordering and payment transactions. One can open 
an e-commerce site using these software tools, or create the whole software 
oneself. However, also when software tools are used, opening of a commerce 

25 site requires at least creation of a product catalogue and customization of the 
application. Establishment of a commerce site resembles the development pro- 
ject of a conventional WWW application. 

[0003] On the Internet there are several methods of payment avail- 
able for electronic commerce. In Finland the most common methods of pay- 

30 ment are cash on delivery, invoicing and on-line bank giro by means of a 
WWW form. Out of Finnish banks Leonia, Merita (Solo service) and Osuus- 
pankki (Kultaraha service) provide interfaces to their bank giro services. Credit 
card payments can be received via a credit card company. For example, pay- 
ments by both Visa and Eurocard/Mastercard can be received and transmitted 

35 to the credit card company (Luottokunta in Finland) by means of SET (Secure 
Electronic Transaction) software intended for retailers, or over an ssl (secure 
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sockets layer) secured connection, in encrypted e-mail, by telephone, fax or 
mail. 

[0004] Regardless of the various alternatives, the problems related 
to payment of products and services are the most important factors that slow 
5 down the spread of chargeable services into the Internet environment. First of 
all, the data security of the e-commerce system requires considerably more 
attention than a conventional web service. In e-commerce chargeable services 
have typically been billed by transmitting the necessary credit card data to the 
service provider who debits the price of the services submitted from the user's 

10 credit card. The users' mistrust and unwillingness to give credit card data to a 
service provider they may not even know limits the use of such services. In 
other methods of payment, on the other hand, the service provider wants to 
ensure that he will really receive the payment from the client before supplying 
a service or delivering a product. This has resulted in complicated systems in 

15 which the data security and the interests of both the service provider and the 
client are ensured. Both parties must have agreements at least with banks or 
other bodies which support this system. Furthermore, the service provider's 
server software has to support the payment protocol in question. However, 
such heavy payment systems are not necessarily suitable for selling services 

20 or goods whose unit prices or sales volumes are low. Such a service could be 
e.g. selling of self-produced magazines, books, pictures or other similar mate- 
rial as electronic files over the Internet. In that case the agreements and soft- 
ware required by secure payment methods and any payment transaction spe- 
cific fees or minimum invoice amounts may prove too laborious or expensive 

25 for a person who plans to open an e-commerce site, and thus prevent this. A 
further problem arises from the fact that a commerce site should preferably 
support as many of the methods of payment the clients want to use as possi- 
ble. 

[0005] The object of the invention is to enable simple and flexible 
30 billing at the server of a service provider in electronic commerce. 

[0006] This is achieved with methods according to claims 1 and 22, 
a telecommunication system according to claim 12 and a server according to 
claims 17 and 26. The preferred embodiments of the invention are described in 
the dependent claims. 
35 [0007] The basic idea of the invention is that the service provider's 

server receives dynamically address data and service attributes of billing ser- 
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vices and servers available in data transmission networks, such as the Inter- 
net, in advertising messages transmitted by billing servers and special direc- 
tory servers. The service provider's server can select one billing service from 
among available billing servers for the billing transaction of a client according 
5 to the parameters given by the client and the above-mentioned service pa- 
rameters, or offer the advertised services for the client to select. Then the ser- 
vice provider's server initiates the billing transaction with the billing server of 
the selected billing service by means of the above-mentioned address data 
and service attributes or transfers billing to the selected billing server, which 

10 performs it. Thanks to the invention, the software of the server can be general 
software, which according to a pre-agreed protocol can, after opening of the 
service, track and start using different methods of payment available on the 
network and offer these to the clients. The rest of the network supports this 
functionality by providing information on billing services according to the 

15 agreed protocol. Furthermore, the server can update the data at suitable inter- 
vals, when necessary or always when the client places an order. The reason 
for sending a service request could be e.g. that the method of payment re- 
quested by the client is unfamiliar to the server. The service attributes may in- 
dicate which billing services require an agreement between the billing server 

20 and the service provider and which services do not. In that case the server or 
the service provider can, if desired, choose billing servers which do not require 
an agreement and/or make an agreement with suitable billing servers. The in- 
vention enables outsourcing of billing transactions from the service provider to 
separate billing servers. 

25 [0008] The server preferably comprises at least general functions 

which are independent of billing and payment protocols and allow tracking and 
selection of a suitable billing server and handshaking with the selected billing 
server. A billing transaction is typically performed according to the digital pay- 
ment or billing protocol supported by the selected billing server. In the first em- 

30 bodiment of the invention the billing server performs the billing transaction. The 
server preferably configures with the payment or billing protocol supported by 
the billing server on the basis of the above-mentioned service attributes re- 
ceived in the advertising message and/or the data, file or software received 
from the billing server after handshaking. At least after configuration the server 

35 software can function as a party in a payment or billing procedure supported by 
the billing server. In an embodiment of the invention the server is configured to 
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transfer the billing transaction to the billing server and the client utilizing the 
attributes supported by the billing server and to receive an acknowledgement 
of the billing carried out from the billing server. The server preferably creates 
an invoice form which is transferred to the client device in a pre-filled form so 
that it can be used in a billing transaction between the client device and the 
billing server. 

[0009] According to an embodiment of the invention, the billing 
server controls the payment or billing transaction after the first handshaking, 
which means that only the client and the service provider's server are parties 
to the transaction. The billing server is preferably also responsible for verifica- 
tion of the client and possibly for that of the service provider, too. and makes 
payment to the service provider. In other words, billing is outsourced to the 
service provider. An advantage of this is that each payment protocol requires 
fewer special functions and smaller software at the service provider's server. 
Furthermore, the service provider does not need to worry about the client's 
honesty or ensure solvency. The client, on the other hand, knows that during 
the payment transaction he is dealing with a familiar party, which he may even 
have chosen himself. 

[0010] In an embodiment of the invention the billing server collects 
service payments made by the client to different service providers and bills the 
client for them in a combined invoice at suitable intervals. The billing server 
may be a billing server owned e.g. by a telecommunication operator, a service 
operator or a similar body with which the client has a service agreement, or it 
may be connected to such a server. In that case the service payments col- 
25 lected for the client can be billed in connection with a normal service invoice of 
such a body, e.g. in a phone bill. This may be a cheaper alternative both for 
the client and the service provider than e.g. electronic bank transfer, particu- 
larly when the invoiced value is small. A telecommunication operator may also 
find this kind of billing service attractive because the growth of business in- 
30 creases traffic on the network and thus telecommunication payments. 

[0011] On the whole, the present invention allows very easy and 
flexible billing when an e-commerce site is opened. 

[0012] In the following, the invention will be described by means of 
preferred embodiments with reference to the accompanying drawings, in which 
35 Ftgure 1 illustrates an embodiment of the invention in the Inter- 

net/Intranet environment, 
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Figure 2 is a flow chart illustrating initialisation of a service pro- 
vider's server according to an embodiment of the invention, and 

Figure 3 is a flow chart illustrating function of the service provider's 
server when it tracks and selects a billing server and establishes a connection 
5 to it during an electronic business transaction, 

Figures 4 and 5 are block diagrams and signalling charts illustrating 
another embodiment of the invention. 

[0013] The present invention is suitable for all telecommunication 
systems where a client device, typically a terminal of a telecommunication 

10 network, can communicate, typically through a TCP/IP protocol stack (Trans- 
port Control Protocol / Internet Protocol), with a server connected to the same 
or to another network. The server may be e.g. a server which generally pro- 
vides services on the Internet and the client a terminal in a wired or wireless 
telecommunication network. 

15 [0014] The Internet is simply a network of networks which supports 

TCP/IP based applications, such as the World Wide Web (WWW), SMTP 
(Simple Message Transport Protocol), Email or FTP (File Transfer Protocol). 
Parts of the Internet are called subnetworks, which are connected to one an- 
other by gateways or routers. The word 'host' is used for computers which are 

20 connected to the network. Often one of the hosts is a 'client' and the other one 
a server. A computer which requests or receives services from another com- 
puter in the network is called a client. The server is a computer which offers 
services for other computers in the network. 

[0015] Figure 1 illustrates the present invention in the Inter- 

25 net/Intranet environment. The service provider's server SPS is connected to 
the Internet to establish a commerce site for electronic commerce where cli- 
ents can buy services or products. In this example the products are files (e.g. 
voice, image, text or multimedia files) or programs which can be transferred 
over the Internet from the server SPS to the client during a business transac- 

30 tion. The interface offered by the commerce site and other implementation are 
not relevant to the invention, except for billing, and will not be described in 
greater detail here. The software solutions can be based on the above- 
mentioned commercial programs intended for electronic commerce, i.e. IBM 
Net.Commerce and Microsoft Site Server Commerce, for instance. In that case 

35 the software usually comprises at least means for creating a product cata- 
logue, for shopping basket management and for receiving orders. 
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[0016] Instead of the above-mentioned commerce site programs, 
the commerce site can also be implemented in a simpler manner by establish- 
ing links on normal WWW pages to chargeable and downloadable files or 
stream-type services (e.g. real time video). These files can be downloaded or 
5 the services initiated after payment has been made according to the principles 
of the invention. According to the preferred embodiments of the invention, the 
server can in that case transfer billing to a separate billing server, which carries 
it out, and wait for confirmation of the billing performed. According to the inven- 
tion, this is feasible because the server can outsource the billing transaction by 

10 means of general software which is configured according to the service attrib- 
utes as will be described below. 

[0017] The client interface is typically based on a WWW site which 
the client can browse like other WWW sites using a commercial browser pro- 
gram included in the client device. The client device can be any computer or 

15 terminal connected to the Internet directly, or, as is typical of private clients, 
through specific Internet operators or Internet access providers' (ASP) dial-up 
servers or gateways, with which the client can establish a modem or an ISDN 
connection over the normal telephone network. The terminals of other net- 
works, such as mobile communication networks, can communicate via special 

20 gateway servers. In that case a mobile station may use the short message 
service (SMS) or the WAP service (Wireless Application Protocol), for exam- 
ple. As was stated above, the client's interface as well as the access method 
by which the client can use the services of the SPS server are not relevant to 
the present invention. 

25 [0018] The general object of the invention is to facilitate establish- 

ment of an electronic commerce site by providing an easy and flexible solution 
for billing. 

[0019] A further object of the invention is to provide outsourcing of 
billing of chargeable services, such as electronic contents, added to the WWW 
30 server and allow electronic payment for delivery of bulk goods of various kind 
reliably without the server needing software means and agreements with 
banks, for example, for carrying out billing. 

[0020] In the preferred embodiment of the invention, the billing soft- 
ware of the SPS server is general software, which according to a pre-agreed 
35 protocol tracks different payment methods/billing servers available on the net- 
work, offers these to its clients and outsources billing to the billing server se- 
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lected by the client according to the pre-agreed protocol. Billing servers and 
agents supporting this functionality are connected to the Internet network by 
giving information on billing services according to this agreed protocol. In the 
preferred embodiment of the invention this agreed protocol is based on the 
5 SLP protocol (Service Location Protocol) standardized for the Internet. This 
protocol has been defined in request for comment RFC 2165 of the Internet 
Engineering Taskforce (IETF). The SLP protocol has been designed for track- 
ing different network resources (printers, servers, fax machines) and for simpli- 
fying their use particularly in company networks and in the Intranet However, 

10 the same principles also apply to the present invention. The SLP is a cli- 
ent/server-based service transmission process which is based on the agent 
technology known per se and which enables dynamic binding of the services 
desired by the user to the network address that transmits the service. In the 
basic architecture of the SLP the user makes a service request from an appii- 

15 cation in his terminal to a user agent on the network, the user agent being a 
program procedure which functions independently of the network on behalf of 
the user and tracks a service according to the attributes defined by the user in 
the network. The servers in the network display the service data of the services 
they offer, such as address and configuration data. Directory agents collect the 

20 service data provided by the servers into one location and thus the directory 
agents have information on all the services available. In the first preferred em- 
bodiment of the invention shown in Figure 1 the service provider's server SPS 
functions in place of the user agent of the conventional SLP protocol and re- 
trieves services for itself, not for the actual user. According to the principles of 

25 the SLP protocol, a number of billing servers BS1, BS2 and BS2 and at least 
one directory agent DA have been connected to the network. The billing serv- 
ers BS1, BS2 and BS3 provide different methods of billing and payment for 
electric commerce. These can be payment services of banks, such as Solo 
service of Merita Nordbanken, Kultakortti payment service of Leonia bank or a 

30 service of a credit card company (e.g. Visa, Mastercard). The billing server BS 
can also be a kind of proxy server which provides the SPS server with an op- 
portunity of using payment services in which one or more other billing servers 
are involved. An example of this will be described below. The billing server BS 
can also be a billing service of another service provider which makes payment 

35 to the SPS server on behalf of the client and bills the client later when it bills 
the client for its own services. In principle, the implementations of the billing 
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servers and the payment and billing protocols used by them are irrelevant to 
the basic functions of the present invention. The billing servers BS1 to BS3 
present service data of the services provided by them, such as address and 
configuration data of the services. The billing servers BS1 to BS3 register the 
5 service data of the billing services they include with the directory agent DA, 
which acknowledges the data it has received. The servers BS1 to BS3 must 
register and update their service data at regular intervals, otherwise the service 
data are deleted from the directories of the directory agent DA. The billing 
servers BS1 to BS3 also inform the directory agent DA of services which have 

10 been removed, in which case the directory agent deletes the service data of 
these services from its directories. Thus the directory agents always have up- 
dated information on the billing services available. 

[0021] The service data naturally include the URL address of the 
service. In addition, the service data preferably comprise different service at- 

15 tributes, which determine the type of the billing service in greater detail. In that 
case the attributes could indicate the name of the service provider, e.g. the 
name of the bank, such as Osuuspankki, Merita, Leonia, Deutsche Bank, or 
the name of the credit card, such as Visa or Mastercard. The attributes can 
also define the digital payment system on which the service is based; in that 

20 case the attributes could be the following: SSL (Secure Sockets Layer), SET 
(Secure Electronic Transaction), First Virtual, Cipher Cash, Digi Cash, and 
Millicent (the four last mentioned are prior art digital payment systems). The 
attributes can also include information on whether the SPS server needs to 
make an agreement in advance with the provider of the billing service or not, 

25 and/or on any billing fee charged by the billing server, e.g. 2% of the total 
price. The attributes may also contain configuration parameters for configuring 
the SPS server to communicate with the billing server and attributes needed to 
outsource billing. The last-mentioned attributes can be used for specifying the 
type and structure of the file, such as an invoice form, used for outsourcing 

30 billing. 

[0022] In the SLP protocol services are defined in greater detail us- 
ing service type templates. An SPL template could have e.g. the following 
form: Semce:billing:http://alma-serv/billing;proto^^ This template defines 

that the billing sen/ice can be found in format at the URL address alma- 
35 serv/billing. For the sake of clarity, the example includes only one service at- 
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tribute which defines SET as the protocol. More attributes can be linked one 
after another to provide all the desired data. 

[0023] The service provider's server SPS can configure with differ- 
ent billing services when it is connected to the network or as clients ask for 
5 different methods of billing or payment. The preferred embodiment of the in- 
vention applies both these principles. First we will describe initialisation of the 
service provider's service SPS with reference to Figures 1 and 2 when an e- 
commerce site is opened. In that case the server has only general software for 
billing, which utilizing the SLP protocol tracks and starts to use different pay- 

10 ment methods available on the network and offers these to the clients. 

[0024] In step 21 of Figure 21 the SPS sends a service request in 
accordance with the SLP protocol, the service request having e.g. the form 
Srvrqst<service:directory-agent>. The request is transmitted as multicast or 
broadcast to the Internet. Since 'directory-agent' has been defined as the ser- 

15 vice type, only directory agents DA react to it. They respond to this sen/ice re- 
quest by sending a DA advertising message DAAdvert, as has been defined in 
the SLP protocol. The DAAvert message contains the address DAAddr of the 
directory agent and a scope list of the services offered by the directory agent. 
In step 22 of Figure 22 the SPS server receives a DAAdvert message. Then 

20 the SPS server selects the data of the billing services from the list and stores 
them in its database. The SPS also modifies the WWW pages of the com- 
merce site by means of the data it has received so that available billing ser- 
vices are offered to the client via a user interface (step 23). In addition, the 
SPS can be already in this step configured to support billing services by means 

25 of the service attributes received in the advertising message. Here configuring 
also refers to combining the payment required of a chargeable sen/ice by the 
service provider with the corresponding service attributes for transferring billing 
data when billing is outsourced, and to introduction of protocols needed to en- 
crypt the traffic between the parties to a billing transaction. The SPS server 

30 can also contact the billing servers and download data, files or software there- 
from, by means of which the server can communicate with the billing servers 
and support their payment and billing protocols (step 24). This configuration 
during initialisation is, however, an optional feature and can also be imple- 
mented so that it is carried out each time the SPS server initiates outsourcing 

35 of billing. 
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[0025] Transmission of the service request (step 21 in Figure 2) is 
. not necessary in the initialisation step, either. The directory agents regularly 
send DAAdvert messages to the network, which the SPS server can receive to 
update its billing service data. The SPS server can also use SLP service re- 
quests of other kinds by means of which the search can be directed straight to 
the billing services or even to billing services of certain type using parameters 
(which are called tags in the SLP protocol). Having received the service re- 
quest message the directory agent DA sends data only on the billing service or 
services the attributes of which match with the parameters (tags) attributes 
given in the service request. The billing servers BS1 to BS3 can also directly 
respond to these service requests by sending information on themselves. If the 
SPS does not know the allowed value ranges of the attributes, it carries' out an 
attribute request according to the SLP protocol and receives the attributes and 
their ranges from the billing server. The data are received directly from the bill- 
ing servers also when there is no directory agent in the network. 

[0026] In the following, an electronic business transaction and a 
payment or billing transaction related to it will be described with reference to 
Figure 3. 

[0027] The client contacts the service provider's server and 
downloads the WWW page of the commerce site to his browser. The client 
browses the product catalogue on the WWW page and selects the product or 
products he wants into the shopping basket. Finally he fills in an order form, 
which also includes selection of the payment method. The client may have a 
number of payment to choose from, which the SPS server has retrieved earlier 
as was described in connection with Figure 2. Alternatively or optionally, the 
client can also give the name or identity of a method of payment which is not 
included in the alternatives given on the order form. In step 31 of Figure 3 the 
client selects a method of payment as described above. After this, the SPS 
server checks its database to find out whether the address data and the ser- 
vice attributes of the billing service or billing server supporting the selected 
method of payment are known (step 32). If a. billing server supporting the se- 
lected method of payment is found, the address data and service attributes of 
the billing server are retrieved from the database (step 33). If the SPS server 
does not know a billing server supporting the method of payment selected by 
the client, the SPS server sends an SLP service request (step 34). The format 
of this service request can be the same as that of the service request Srvrqst 
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which was used in connection with initialisation of the SPS server. The Srvrqst 
message preferably comprises more detailed parameters (tags), by means of 
which the search is restricted to billing service of certain, kind. Such a parame- 
ter can be the name of the bank, for example. In step 35 the SPS server re- 
5 ceives a reply message, which according to the SLP protocol, for example, is a 
service reply Srvrply. The reply message includes the URL address of the ser- 
vice and service attributes for at least one billing service which conforms to the 
parameters defined in the service request. It should be noted that reply mes- 
sages can arrive from several directory agents or billing servers. In step 36 the 

10 SPS server selects one billing service for use in the on-going payment transac- 
tion (step 36) on the basis of the replies it has received. At the same time the 
SPS server can update the data of the billing servers given in the replies into 
its database, provided that the servers are new. The criteria of the SPS service 
provider can also affect the selection of the billing server, such as whether a 

15 preliminary agreement is needed, which payment protocol is used, etc. 

[0028] After the billing service has been found and the address data 
and service attributes of the billing server have been received, the SPS server 
sends a service request to the selected billing server on the basis of said ad- 
dress data. Before this, the SPS server may (at least preliminarily) configure to 

20 the payment or billing protocol of the billing server or at least communicate with 
the billing server using the above-mentioned service attributes. The connection 
between the SPS server and the billing server is preferably established as an 
ssl connection to ensure security. This may be followed by final configuration 
of the SPS server to support the payment or billing protocol of the billing server 

25 by means of the data, files or software downloaded from its billing server (step 
36). After this the SPS server can function at least as one party in a billing or 
payment transaction which the billing server, e.g. BS1 , controls. 

[0029] As was stated above, the digital payment or billing protocol 
or system used by the billing server is not relevant to the invention. As a result 

30 of this, the client, the SPS server and the billing server BS1 can interact to 
complete a payment transaction in any manner. A separate secured connec- 
tion can be established between the client and the billing server BS1 as the 
billing server BSIand the SPS server communicate over another secured con- 
nection. The ordering and billing program of the SPS server supplies at least 

35 the price of the service or product sold and the account to which the payment 
should be made to the billing server BS1. Data needed to identify the client, 
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product information (list of ordered goods) and an invoice number are prefera- 
bly also supplied. Authentication of the parties can also be carried out between 
the billing server BS1 and the SPS. Authentication comprises exchange of cer- 
tificates issued by a reliable body and public keys of the parties. In principle, 
5 this is included in the handshaking carried out when an SSL-secured connec- 
tion is established but it can also be included in the functions of an upper pro- 
tocol layer. 

[0030] An advantage provided by the invention is that billing func- 
tions can be outsourced from the service provider's server SPS to a separate 

10 billing server. In that case the billing server BS1 can have necessary agree- 
ments with banks, for example, and thus the billing server BS1 can function as 
the virtual 'seller* in a payment transaction in accordance with the SET proto- 
col. The service provider, who actually sells goods or services on the server 
SPS, does not necessarily agreements of his own. From the point of view of 

15 the billing server BS1 , the client and the bank, the payment transaction is car- 
ried out as if the product had been purchased from the billing server BS1. The 
billing server BS1 only makes payment to the actual service provider, e.g. to 
his account, as a separate function. The billing server BS1 can charge a cer- 
tain percent of the total price as a commission for the service before crediting 

20 the payment to the service provider. This percent can be one of the attributes 
included in the service data sent by the directory server and one of the selec- 
tion criteria of billing servers in the SPS server. In the following, a payment 
transaction applying this principle will be described. 

[0031] It is assumed that e-commerce between the client and the 

25 SPS server is now in the situation where it was in step 38 of Figure 3. The SPS 
server receives the SET program from the billing server BS1 , which is for- 
warded to the client's browser e.g. by sending a document including a special 
MIME type, ActiveX control or Java aplet. The client's SET program generates 
two messages. The first message contains order information consisting of the 

30 total purchase price and the order number. The second message contains 
payment information consisting of the client's credit card number and bank in- 
formation. The order information is encrypted using a random symmetric ses- 
sion key and packed into a digital envelope using the public key of the SPS 
server. The payment information is encrypted in the same way, except that the 

35 public key of the billing server BS1 (which functions as the 'seller') is used. 
This prevents the SPS server or the billing server BS1 from finding out the 
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credit card number or the bank from the order information. Then the client's 
software calculates a common hash for the order and payment information and 
signs it with the clients private key. This results in a 'double signature 1 , which 
allows the SPS server, the billing server BS1 and the bank of the billing server 
5 BS2 to verify the authenticity of both message without being able to read the 
part intended for the other parties. The SPS server decrypts a received digital 
envelope with its own private key and the transfer information with the above- 
mentioned random symmetric session key. The SPS server adds its account 
and bank information to the order information and encrypts the order informa- 

10 tion with another random symmetric session key which is used between the 
SPS server and the server BS1 and packs the information into a digital enve- 
lope using the public key of the billing server BS1. After this, the SPS server 
forwards the order information and the client's payment information to the bill- 
ing server BS1. The SET software of the billing server BS1 generates an au- 

15 thorization request, which transmits the client's payment information to the 
SET server (e.g. billing server BS2) of the bank of the billing server BS1. The 
billing server BS1 signs the authorization request with its private key to prove 
its identity to the bank. This request is encrypted with a new random session 
key and inserted into a digital envelope using the bank's public key. 

20 [0032] The bank, i.e. billing server BS2, decrypts the seller's au- 

thorization request and verifies the seller's identity. After this, the server has to 
obtain authorization from the client's bank, e.g. from the billing server BS3. The 
BS2 generates an authorization request of its own, signs it and forwards to the 
bank that has issued the credit card (server BS3). The BS3 verifies the identity 

25 of the server BS3, decrypts the information and checks the client's account. If 
the account is in order, the server BS3 accepts the authorization request by 
signing it and returning it to the server BS2. The server BS2 authorizes the 
transaction, signs it and sends the affirmative reply back to the server BS1. 
The BS1 completes the transaction. The BS1 acknowledges to the client that 

30 the card has been accepted by showing an acceptance page to the client. 
Then the BS1 sends a message to the server BS2 which confirms the pur- 
chase and causes debiting of the client's credit card account and crediting of 
the account of the server BS1 . 

[0033] After this the billing server BS1 calculates the sum that is to 

35 be credited to the actual service provider after the billing fee has been de- 
ducted. Then the BS1 contacts the server BS2 of its bank e.g. over an SSL- 
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secured connection and performs bank giro from its own account to the service 
provider's account. After this, the billing server BS1 sends confirmation to the 
service provider's server SPS that the payment transaction has been com- 
pleted successfully. The SPS server feeds the clients order into an order proc- 
5 essing system and delivers the goods to the client or supplies the requested 
service. The client can download the desired files or programs from the server 
SPS to the client device. 

[0034] In the second example the billing server BS1 functions as a 
proxy server, which maintains billing data resulting from supply of chargeable 

10 services and transmits these data to the billing server (e.g. server BS2) of the 
telecommunications operator used by the client for billing in the client's phone 
bill. After a connection has been established between the service provider's 
server SPS and the billing server BS1 as shown in Figure 3, the SPS server 
sends the client's IP address (or another identifier which the telecommunica- 

15 tions operator can use for identifying the client) and the service provider's ac- 
count data to the billing server BS1 . The billing server BS1 can use the client's 
address to find out to which Internet subnetwork the client is connected. When 
the billing server BS1 finds this out, it checks its own database to find out via 
which telecommunications operator this client is connected to the network. By 

20 means of this information the BS1 contacts the billing server BS2 of the tele- 
communications operator and negotiates with the billing server BS2 about 
whether billing can be included in the phone bill. If this can be done, the billing 
server BS1 checks that the client is aware that the service is chargeable and is 
willing to pay for it. Acknowledgement can be performed e.g. by a combination 

25 of the public key and the private key, in which case there is no doubt about the 
client's identity. Having received an acknowledgement of this, the billing server 
BS1 informs the service provider's server SPS that the service can be sup- 
plied. After the server SPS has supplied the service or product in question to 
the client, it sends an acknowledgement to the billing server BS1, which initi- 

30 ates signalling needed for billing to the server SPS and the billing server BS2 
of the telecommunications operator. The billing server BS2 of the telecommu- 
nications operator collects the client's service fees and bills the client for them 
together with other telecommunications payments in the phone bill. 

[0035] Figures 4 and 5 illustrate an embodiment where the service 

35 provider's server SPS creates or downloads a file used for outsourcing of bill- 



# 



WO 01/78316 PCT/FI01/00339 

15 

ing, such as an invoice form, on the basis of the billing service attributes sent 
by the directory agent. 

[0036] The billing server BS1 updates its information to the directory 
agent (step 41) and the DA sends information on the billing services in a 
5 DAAdvert message as was described in connection with the preceding em- 
bodiments. In the SPS server the commerce site comprises normal WWW 
pages 51 , which comprise links 52 to chargeable downloadable files or stream 
services (e.g. real time video). These files can be downloaded or the services 
initiated after billing has been carried out according to the principles of the in- 

10 vention. Naturally the service on sale can be any other service or product. 
When the client contacts the SPS server, the WWW page(s) 51 is (are) trans- 
ferred to the browser of the client device (step 42). When the client wants to 
order a service or a product, he activates the link 52 to the service in question 
e.g. by clicking the mouse. As a result of link activation the client device re- 

15 quests (message 43) the WWW page in question from the SPS server. The 
requested WWW page 53 presents the methods of payment available to the 
user and includes a link 54 and 55 for each method of payment. The WWW 
page has been created on the basis of the advertising messages of the billing 
servers obtained from the network according to the principles described in 

20 connection with the preceding embodiments. The page information is prefera- 
bly initialised when a commerce site is being established and it is updated 
regularly or when advertising messages are received from the network. The 
information on the WWW page 53 can also be updated always when the page 
is requested but this may cause delay in downloading of the pages. The WWW 

25 page 53 is transferred to the browser of the client device (step 44). The client 
selects the desired billing service and activates the corresponding link, which 
in the example is the link 54 of the Solo bank service. As a result of link 54 ac- 
tivation, the client device requests the invoice form of the selected billing ser- 
vice (message 45). The SPS server creates a www page which includes the 

30 structures, data and fields defined by the attributes received in the advertising 
message. In other words, the attribute values of each billing server contain 
enough information for creating an invoice form (e.g. on a blank retrieved from 
the network) in the format accepted by the billing server. The SPS server ob- 
tains the protocol data, URL address and attributes of the billing servers and 

35 possibly the type information of the invoice form as the value of the invoice 
form attribute from the advertising message DAAdvert. On the basis of the in- 
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voice form type the SPS server can download a blank invoice from the billing 
server, for example. Which invoice form will be used depends on the type of 
the invoice form supported by the billing server. Invoice forms can also be 
generated without a blank by using the names of the billing attributes as soft- 
5 ware references to the fields of the invoice form and any individual attribute 
values of each billing transaction as the values of these fields. When this ar- 
rangement is used, the SPS server can easily create an invoice form which is 
sent to the client as a WWW page, for example, so that the format and content 
of the form correspond to the requirements of the billing server. 

10 [0037] In Figure 5 the invoice form of the WWW page 56 includes 

fields 57. Before the invoice form is sent to the client device, the SPS server 
adds to the suitable fields of the form the reference number of the invoice, the 
service provider's reference number and the URL address to the directory of 
the SPS server to which the billing server later sends an acknowledgement of 

15 the billing carried out. Furthermore, the SPS adds a link 58 to the billing server 
BS1 to the form. The protocol data and URL address of the chargeable service 
ordered by the client are also added to the information included in the form. 
The billing server BS1 uses these data when it registers billing transactions 
and configures a WWW page which is sent to the client as an acknowledge- 

20 ment of billing. The WWW page must include a link which generates a request 
by means of which the desired service is actually transmitted to the client. 

[0038] The WWW page is transferred to the client device (step 46). 
The client fills in the invoice form with his own data, such as his account num- 
ber and name. The client can also encrypt and sign these data with his private 

25 key if the client's public key is available to the billing server. Having filled in the 
invoice form, the client clicks on link 58 on the form, as a result of which the 
invoice form is transferred to the billing server BS1 (step 47). This transfer can 
comprise establishment of a secured connection between the client device and 
the billing server BS1, or other operations. After this the billing transaction is 

30 carried out as a transaction between the client and the billing server BS1 (step 
48) according to the payment protocol used.. 

[0039] After billing has been carried out the billing server BS1 sends 
an acknowledgement 49 of successful billing to the service provider's URL ad- 
dress, which the SPS server added to the invoice form. The acknowledgement 

35 includes the reference number of the invoice, which the SPS server also added 
to the invoice form. By means of this reference number the SPS server can 
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combine an acknowledged billing transaction with the correct client, i.e. with 
the client's IP address. At this stage the SPS server does not necessarily have 
any other information on the client because the invoice form filled in by the cli- 
ent has not been sent to the SPS server. The SPS server saves the informa- 
5 tion on successful billing. The acknowledgement sent by the billing server BS1 
may have been signed with the private key of the BS1 so that the SPS can 
verify the sender of the acknowledgement. The SPS and the BS1 can also 
communicate otherwise, depending on the payment protocol. 

[0040] As an acknowledgement of billing the billing server BS1 

10 sends (step 50) a WWW page 59 to the client, the page including a link 60 to 
the service the client wants. This link has been established employing the pro- 
tocol information and the URL address of the chargeable service the client 
wants to have, which were added to the invoice form by the SPS server. The 
page 59 may also contain an invoice reference number. 

15 [0041] The client clicks on link 60 on the WWW page 59 when he 

wants to receive the service. As a result of link 60 activation the client device 
sends a service request 61 to the SPS server. Having received the service re- 
quest the SPS server checks using the IP address and/or the reference num- 
ber that it has an acknowledgement of successful billing. If an acknowledge- 

20 ment is found, the SPS server carries out the service according to the service 
request, step 62. After the service has been completed, the SPS server stores 
information on this in the billing file so that later service requests with the same 
data can be rejected. If implementation of the service is interrupted (e.g. due to 
a connection failure), the billing file remains blank and the client can renew the 

25 service request. 

[0042] In this embodiment of the invention no delicate information 
on the client, such as account numbers, are transmitted via the SPS server. 
Furthermore, billing has been completely outsourced, except for creation and 
pre-filling of the invoice form. 

30 [0043] According to the preferred embodiments of the invention, the 

server can in that case transfer billing to a separate billing server which carries 
it out and wait for confirmation of billing carried out. The invention enables this 
because the server can outsource the billing transaction by means of general 
software which is configured according to the attributes of the billing server in 

35 the manner to be described below. The invention has been described by 
means of preferred embodiments. The invention is not, however, limited to 
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these embodiments, but a person skilled in the art can implement the invention 
in various ways without deviating from the scope and spirit of the attached 
claims. 
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